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Abstract 


The  aim  of  this  work  is  to  enable  a  more  rigorously  tested  product  by  integrating  protocol 
specification  and  conformance  test  sequence  generation.  Such  an  integration  will  allow  for  the 
removal  of  costly  mistakes  from  a  specification  at  an  early  stage  of  the  development  process 
before  they  propagate  into  different  implementations,  possibly  combined  with  other  errors.  This 
integrated  approach  has  been  applied  to  the  VHDL  specification  of  a  military-oriented  protocol 
prototype  called  the  “Local  Proxy.”  Based  on  the  results  of  the  conformance  test  generation 
process,  the  Local  Proxy  specification  has  been  refined  by  uncovering  various  missing  actions, 
removing  redundancies,  and  restructuring  the  specification  to  improve  its  testability. 
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1.  Introduction 


Today  more  than  ever,  society  relies  on  systems  built  using  complex  software  and  hard¬ 
ware  components.  The  military  is  no  exception,  relying  on  these  technologies  for  almost 
every  task  from  the  foxhole  to  the  command  center.  However,  there  have  been  many  well- 
advertised  failures  of  both  software  and  hardware  components  in  mission-critical  systems. 
One  approach  for  reducing  this  problem  is  increasing  the  effectiveness  of  conformance  testing 
by  combining  it  with  the  development  process.  The  goal  of  conformance  testing  is  to  find 
discrepancies  between  a  protocol’s  specification  and  its  implementation.  Recent  advances  in 
telecommunications  systems  development  have  shown  the  advantages  of  using  conformance 
testing  techniques  as  an  integral  part  of  the  development  process. 

A  protocol’s  external  behavior  is  often  modeled  as  an  extended  finite-state  machine 
(EFSM) — a  finite-state  machine  (FSM)  that  has  access  to  storage  variables.  Due  to  the  ex¬ 
istence  of  context  variables,  timers,  etc.,  automated  conformance  test  generation  for  EFSMs 
is  a  challenging  task. 

Test  generation  methods  available  for  the  FSM  models  are  only  applicable  to  protocols 
modeled  as  consistent  EFSMs  [1].  An  EFSM  is  said  to  be  consistent  if  it  is  free  of  condition- 
to-condition,  action-to-condition,  and  action-to-action  inconsistencies.  These  inconsistencies 
occur  when  the  variables  of  the  actions  and/or  conditions  are  updated  differently  by  the  ac¬ 
tions  of  the  specification  and/or  when  the  same  variable  is  used  by  more  than  one  condition. 
(Note  that  these  so-called  inconsistencies  in  a  specification  are  only  impediments  to  the 
automated  test  generation  techniques;  their  presence  does  not  imply  errors  in  the  specifi¬ 
cation.)  The  Very  high-speed  integrated  circuit  Hardware  Description  Language  (VHDL) 
is  a  hardware  description  language  used  for  specifying  the  behaviour  of  hardware  and  soft¬ 
ware  protocols.  Algorithms  for  removing  the  inconsistencies  from  VHDL  specifications  were 
reported  in  [2]. 

The  objective  of  this  report  is  to  propose  the  integration  of  protocol  specification  and 
conformance  test  sequence  generation  to  enable  a  more  rigorously  tested  product.  Such  an 
integration  will  allow  for  the  removal  of  costly  mistakes  from  a  specification  at  an  early 
stage  of  the  development  process,  before  they  propagate  into  different  implementations,  pos¬ 
sibly  combining  with  other  errors.  In  this  report,  the  inconsistency  detection  and  removal 
algorithms  of  [1,  2]  are  applied  to  generate  test  sequences  for  a  military-oriented  communi¬ 
cation  protocol  prototype.  The  Adaptive  Computing  Architecture  (AC A)  [3],  which  takes 
into  consideration  managing  the  ever-changing  defence  network  resources  (according  to  pre¬ 
defined  network  policies),  is  used  as  a  case  study.  The  VHDL  specification  of  the  Local 
Proxy  component  of  the  ACA  has  been  refined  through  conformance  test  generation. 

Section  2  gives  a  description  of  the  ACA,  particularly  the  Local  Proxy.  Section  3  discusses 
generating  a  test  sequence  for  the  Local  Proxy.  Section  4  presents  refinements  for  the  Local 
Proxy.  Section  5  draws  our  conclusions.  The  Appendix  presents  the  VHDL  specification  for 
the  Local  Proxy. 
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2.  Case  Study:  The  Local  Proxy  of  the  Adaptive 
Computing  Architecture 

The  requirements  of  defence  networking  and  computing  present  significant  challenges 
to  current  architectures  for  distributed  computing.  In  particular,  the  mix  of  distributed 
computing,  networks  that  provide  variable  bandwidth  and  reliability,  and  mission-critical 
applications  that  must  use  these  networks  demands  new  approaches  to  building  application 
architectures.  The  ACA  has  been  proposed  as  a  framework  based  on  open  distributed 
processing  (ODP)  bindings  that  supports  policy-based  adaptive  management  of  network 
resources  [3]. 

An  adaptive  network  resource  management  framework  needs  to  maintain  three  key  kinds 
of  information  about  the  system.  First,  management  policies  need  to  be  modelled  to  allow 
adjustments  of  policy  at  runtime.  Second,  the  interface  specifications  and  Quality  of  Service 
(QoS)  requirements  of  applications  and  services  need  to  be  modelled  so  that  the  management 
system  can  support  a  dynamic  environment  of  communicating  objects.  Finally,  network 
topology  and  QoS  measures  need  to  be  modelled  so  that  the  management  system  can  make 
appropriate  decisions  based  on  network  conditions.  Figure  1  is  a  high-level  logical  depiction 
of  the  ACA.  At  the  centre  of  the  architecture  is  the  Adaptive  Quality  of  service  Manager 
(AQM)  that  manages  resources  to  satisfy  application  requirements  according  to  current 
adaptation  policies  and  network  conditions. 


Figure  1.  Adaptive  Computing  Architecture. 

The  Policy  Service  stores  the  current  adaptation  policies.  The  Network  Quality  of  service 
Manager  (NQM)  maintains  the  system’s  model  of  the  network  topology,  QoS,  and  the  current 
state  of  the  network.  The  Local  Monitor  (LM)  performs  monitoring  of  QoS  delivered  to 
applications.  The  Type  Manager  is  an  ODP  service  and  is  used  to  store  interface  and  QoS 
descriptions  for  applications  and  services.  The  Trader  is  another  ODP  function  that  manages 
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current  offers  of  service  and  matches  them  against  requests  from  clients  via  the  AQM. 


2.1  Adaptive  QoS  Manager 

The  function  of  the  AQM  is  to  establish  and  manage  bindings  between  application  and 
service  objects.  While  these  bindings  are  made  at  the  request  of  individual  client  objects, 
the  AQM  is  responsible  for  managing  enterprise  resource  usage  according  to  the  current 
policies.  This  is  done  by  mediating  new  requests  for  service  and  actively  managing  resource 
usage  by  existing  bindings.  The  emphasis  of  the  AQM,  its  information  model  and  actions, 
is  on  dealing  with  loss  of  service  for  critical  applications — typically  this  involves  managing 
heterogeneous  wide-area  network  resources. 

If  network  resources  are  not  available  (and  policy  dictates),  the  AQM  may  take  action 
to  manage  resource  usage.  In  the  worst  case,  it  can  pre-emptively  shut  down  an  existing 
binding  from  another  application  to  free  up  resources.  The  AQM  can  also  adjust  an  existing 
binding  to  optimise  its  resource  usage.  For  example,  it  could  cause  the  binding  to  change 
the  service  objects  and  communications  paths  used  to  shed  load  from  overloaded  network 
links.  Similarly,  network  load  can  be  reduced  by  inserting  filter  objects  within  a  binding. 


2.2  Policy  Service 

The  Policy  Service  stores  the  adaptation  policies  that  specify  how  and  when  the  AQM 
should  adapt  to  changing  resource  availability.  Adaptation  policies  typically  fall  into  one  of 
three  categories:  (1)  usage  preferences  that  are  specific  to  a  particular  kind  of  application, 
(2)  policies  that  address  the  trade-off  of  cost  vs.  performance  and  (3)  policies  that  are 
modal  and/or  sensitive  to  user  identity.  As  an  example  of  category  (3),  when  a  field  unit 
is  on  high  alert,  only  messages  authorised  by  particular  officers  should  be  sent  over  the 
unit’s  high-frequency  link.  Our  model  for  adaptation  policies  is  based  on  Sloman’s  policy 
language  [4]. 


2.3  Network  QoS  Manager 

The  NQM  is  the  component  in  the  adaptive  resource  management  architecture  that 
holds  knowledge  of  the  state  of  the  network.  This  knowledge  consists  of  two  distinct  parts. 
The  nominal  network  topology  and  its  associated  QoS  measures  (e.g.,  link  capacities)  are 
expressed  using  the  Network  Quality  of  service  Specification  Language  (NQSL)  described  in 
McClure  et  al.  [5]. 

The  second  knowledge  component  maintained  by  the  NQM  deals  with  the  current  network 
state.  The  NQM  must  be  informed  of  the  current  network  load  by  management  interfaces  on 
critical  links  and  gateways.  The  NQM  may  also  receive  monitoring  information  from  LMs 
regarding  the  QoS  delivered  to  established  bindings. 

The  other  functions  of  the  NQM  include  using  the  information  that  it  gathers  to  perform 
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route  selections  and  preemption  on  the  basis  of  required  QoS  parameters.  This  function  is 
used  by  the  AQM  to  allow  it  to  make  optimal  service  selections  if  there  are  several  servers 
available. 

To  validate  the  ACA  it  is  desirable  to  test  it  on  a  larger  network  than  that  used  by  our 
inital  prototype.  The  Australian  Defence  Science  and  Technology  Organisation  (DSTO)  is 
currently  building  an  Experimental  C3I  Technology  Environment  (EXC3ITE).  This  envi¬ 
ronment  is  an  interstate  heterogeneous  network  infrastructure  including  satellite  links.  The 
EXC3ITE  network  will  support  a  number  of  emerging  Common  Object  Request  Broker  Ar¬ 
chitecture  (CORBA)-based  applications.  Potential  users  of  the  EXC3ITE  network  require 
method  for  moderating  the  use  of  network  resources  in  this  environment.  Therefore  the 
EXC3ITE  network  has  been  modelled  as  a  realistic  exemplar  heterogeneous  defence  network 
to  support  this  simulation. 

The  simulation  model  of  the  ACA  represents  an  implementation  of  the  architecture. 
The  AQM  is  implemented  as  two  distributed  components.  The  first  part  is  a  Local  Proxy, 
which  together  with  the  policy  service  is  present  on  all  workstations.  This  part  of  the  AQM 
implements  policies  local  to  the  workstation  and  provides  an  interface  between  applications 
and  the  architecture.  Second,  aspects  of  the  AQM  that  have  wider  impact  form  part  of  a 
LAN  proxy. 

The  main  function  provided  by  the  Local  Proxy  process  is  to  manage  a  set  of  Local 
Proxy2  processes,  which  in  turn,  redirect  application  requests  to  the  Local  Area  Network 
(LAN)  Proxy  component  and  performs  local  monitoring  for  the  application.  The  relationship 
between  Local  Proxy  and  Local  Proxy2  processes  is  depicted  in  Figure  2. 


Figure  2.  The  Local  Proxy  of  ACA. 

The  behavioral  model  of  a  VHDL  specification  can  be  used  as  a  formal  description  for 
a  communication  protocol  [6,  7].  The  behavioral  model  of  the  Local  Proxy  component  has 
been  specified  in  VHDL,  where  the  architecture  is  represented  in  a  single  process.  An  EFSM 
representation  of  the  Local  Proxy  is  constructed  from  its  VHDL  behavior  description  (since 
internal  variables  are  used  in  the  specification,  a  simpler  FSM  model  could  not  be  utilized). 
The  main  functionality  of  the  Local  Proxy  component  is  depicted  when  the  component  is 
in  its  listen  mode.  A  portion  of  the  EFSM  model  of  the  Local  Proxy,  that  portrays  the 
component’s  listen  mode,  is  presented  in  Figure  3.  For  simplicity,  the  number  of  connections 
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is  assumed  to  be,  at  most,  two.  In  the  specification,  when  the  else  part  of  an  if  statement  is 
missing,  a  “complementary”  else  statement  with  a  null  output  is  created.  The  complemen¬ 
tary  edges  of  Figure  3  include  e26,  e 28 ,  ^36,  and  e42. 


Figure  3.  EFSM  Model  of  the  Local  Proxy. 


3.  Test  Generation  for  the  Local  Proxy 

The  VHDL  specification  for  the  Local  Proxy  of  the  ACA  is  an  EFSM  that  can  be  used 
to  automatically  generate  conformance  tests.  An  EFSM  model  requires  the  detection  and 
removal  of  the  inconsistencies  among  the  conditions  and  actions  of  its  specification  (if  any)  [1, 
2]- 

The  algorithm  presented  in  Uyar  and  Duale  [1]  uses  symbolic  execution  [8]  with  graph¬ 
splitting  techniques  to  detect  inconsistencies.  Based  on  the  variables  used  in  the  actions  and 
conditions,  infeasible  paths  are  searched  in  the  EFSM  model.  If  at  least  one  infeasible  path 
is  found,  the  EFSM  is  called  inconsistent,  otherwise  the  EFSM  is  consistent. 

The  EFSM  model  of  the  Local  Proxy  is  found  to  be  inconsistent.  As  mentioned  ear¬ 
lier,  finding  inconsistencies  in  an  EFSM  model  simply  means  that  some  edges  in  the  graph 
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representation  of  the  EFSM  cannot  be  traversed  together  with  certain  other  edges.  For  ex¬ 
ample,  a  test  sequence  with  the  edges  e27,  e37,  and  e43  requires  TCP JCI.IN. INF. TYPE  to 
be  ESTAB,  SG.FWD ,  and  CLOSE/ ABORT,  respectively.  Executing  a  test  sequence  such  as 
TCP  JCI.IN -INF-TYPE  is  not  feasible  because  the  input  signal  is  not  updated  in  the  walk 
containing  these  edges. 

Once  the  inconsistencies  are  detected  in  the  Local  Proxy,  they  can  be  removed  from  the 
EFSM  model  by  the  two  algorithms  reported  in  Uyar  and  Duale  [2].  The  first  algorithm 
eliminates  the  action-to-condition  and  action-to-action  inconsistencies  from  the  EFSM  model 
of  the  Local  Proxy.  If  the  conditions  for  outgoing  edges  of  st  use  variables  modified  in  the 
paths  leading  to  then  and  all  nodes  accessible  from  it  are  split  into  parallel  subgraphs. 
The  number  of  times  that  a  node  is  split  is  determined  by  the  number  of  different  val¬ 
ues  for  the  variables  causing  the  inconsistencies  at  s*.  The  second  algorithm  removes  the 
condition-to-condition  inconsistencies.  During  the  removal,  path  conditions  up  to  node  s, 
are  accumulated.  If  the  conditions  for  outgoing  edges  from  st  conflict  with  the  accumulated 
path  conditions,  and  all  nodes  accessible  from  it  are  split  into  parallel  subgraphs.  The 
number  of  times  that  a  node  is  split  depends  upon  the  number  of  condition  sets  for  the 
variables  of  the  outgoing  edges  of  s*. 

During  the  node  splits,  a  node  that  can  be  accessed  from  s,  is  split  only  if  there  is  a 
path  between  the  two  nodes,  without  any  intermediate  read  condition(s)  for  the  variable(s) 
that  are  causing  inconsistencies.  For  example,  in  the  Local  Proxy,  because  of  the  “wait” 
statement  in  e4g  (i.e.,  a  “read”  type  of  statement),  the  nodes  accessible  from  .s2s  are  not 
split.  Figure  4  shows  the  final  graph  after  infeasible  edges  were  deleted,  which  is  free  of 
inconsistencies,  obtained  by  the  algorithms  of  Uyar  and  Duale  [2]. 

The  conformance  tests  for  the  Local  Proxy  are  generated  by  using  the  Rural  Chinese  Post¬ 
man  (RCP)  method,  which  combines  the  rural  postman  tours  and  the  unique  input /output 
(UIO)  sequences  [9] .  The  RCP  method  is  developed  for  FSM  models  and,  therefore,  can¬ 
not  address  the  issue  of  inconsistencies.  However,  after  the  inconsistencies  are  removed,  the 
EFSM  model  of  a  specification  effectively  becomes  an  FSM  model  that  can  be  used  with  the 
RCP  method.  A  minimum- length  test  sequence,  generated  by  the  RCP  method  for  the  Local 
Proxy,  consisting  of  192  steps  is  shown  in  Table  A-2,  in  the  Appendix.  (During  this  early 
step  of  the  case  study,  the  test  sequence  was  generated  without  using  the  UIO  sequences.  A 
single  test  step  was,  however,  dedicated  for  each  state  that  needs  to  be  verified.) 


4.  Refining  the  Local  Proxy 


During  the  initial  phase  of  a  protocol  design,  it  is  important  that  the  external  func¬ 
tionality  of  the  protocol  is  well-defined,  while  the  internal  functionality  is  considered  as  a 
black  box  [10].  This  hierarchical  approach  enables  a  successful  process  cycle  of  design,  de¬ 
velopment  and  conformance  testing.  Within  this  framework,  conformance  test  generation 
for  the  Local  Proxy  produced  several  specification  changes.  Various  recommendations  were 
presented  to  the  protocol  designers  to  enhance  the  completeness  of  the  Local  Proxy  specifica¬ 
tion  and  improve  its  testability.  The  following  sections  highlight  the  observations  regarding 
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Figure  4.  EFSM  Model  of  the  Local  Proxy  After  Inconsistencies  Were 
Removed. 

the  testability  of  Local  Proxy. 

4.1  Redundancies  in  Specifications 

UIO  sequences  are  planned  to  be  used  for  the  state  verification  during  conformance 
testing.  It  has  been  shown  that,  if  a  state  of  an  FSM/EFSM  does  not  have  an  equivalent 
state,  it  possesses  a  UIO  sequence  [11].  Two  states  are  said  to  be  equivalent  if  the  permissible 
input  set  for  one  is  a  subset  for  the  permissible  input  set  of  the  other  and  the  corresponding 
outputs  and  next  states  are  the  same  [12].  Two  states  are  also  k-equivalent  if  the  pair  cannot 
be  distinguished  with  a  sequence  of  length  k.  The  main  reason  that  UIO  sequences  cannot  be 
used  for  FSMs/EFSMs  containing  equivalent  states  is  due  to  the  inability  to  detect  transfer 
errors.  A  transfer  error  on  an  edge  from  state  Si  to  Sj  can  cause  the  implementation  under 


test  (IUT)  to  move  to  a  different,  but  equivalent ,  state  from  Sj.  Failure  to  identify  a  state 
may  allow  for  nonconformant  IUTs  to  successfully  pass  the  conformance  tests. 

To  describe  the  protocol  behavior  precisely,  a  protocol  designer  may  repeat  certain  por¬ 
tions  of  the  specification  several  times.  Such  redundancies  will  eventually  lead  to  the  for¬ 
mation  of  equivalent  states,  impairing  the  testability  of  the  IUT.  Therefore,  balancing  the 
clarity  of  the  specification  with  its  testability  is  an  important  issue  to  be  addressed  at  the 
design  stage. 

In  the  process  of  forming  UIO  sequences  for  the  Local  Proxy,  it  is  observed  that  some 
of  the  states  produce  identical  outputs  for  the  same  inputs  and  their  next  states  are  2  or 
3-equivalent.  For  example,  the  input/output  set  for  S20  is  identical  to  that  of  S15  and  the 
sets  of  their  adjacent  nodes  ({sja,  $21}  for  s2o  and  {si4,  si6}  for  s15)  contain  2  or  3-equivalent 
nodes.  Therefore,  nodes  S19,  S20,  and  S21  can  be  merged  with  $i4,  S15,  and  s16,  respectively. 
Since  the  number  of  nodes  and  edges  will  be  reduced  after  the  merge,  the  length  of  test 
sequence  will  be  also  shorter. 

For  testing  purposes,  the  behavior  of  an  EFSM  is  transformed  to  an  FSM  by  duplicat¬ 
ing  some  of  the  nodes  and  edges  of  the  EFSM  graph  [1,  2].  The  number  of  states  could 
dramatically  increase  if  proper  methods  of  expansion  are  not  employed.  The  removal  of  the 
redundant  states  is  also  helpful  in  reducing  the  number  of  states  in  the  final  EFSM  graph. 


4.2  Reachability- 

Conformance  testing  methods  require  that  each  node  of  the  directed  graph  of  the  FSM/ 
EFSM  model  of  the  specification  can  be  reached  from  any  other  node. 

During  the  inconsistency  removal  process,  the  EFSM  graph  is  split  into  subgraphs.  In¬ 
feasible  transitions  are  dropped  from  the  new  subgraphs.  A  node  with  no  incoming  edges 
becomes  unreachable  and  is  removed  from  the  graph.  The  final  graph  with  no  inconsistencies, 
shown  in  Figure  4  for  the  Local  Proxy,  has  no  unreachable  nodes. 

As  indicated  in  section  2,  the  EFSM  model  of  the  Local  Proxy  contains  complementary 
edges  (i.e.,  the  edges,  with  null  outputs,  created  for  if  statements  whose  corresponding  else 
statements  were  not  present  in  the  VHDL  specification)  such  as  e26,  e28,  and  e36.  The  actions 
of  these  complementary  edges  of  Local  Proxy  are  further  discussed  with  the  designers  to 
clarify  if  they  were  inserted  correctly.  During  these  discussions,  it  is  observed  that  some  of 
the  complementary  edges  were  the  only  edges  connecting  some  subgraphs  to  the  rest  of  the 
EFSM  graph.  For  example,  if  e26  and  e28  (complementary  edges)  were  removed  from  Figure  4, 
S22.1  and  Sis  would  become  nodes  without  incoming  and  outgoing  edges,  respectively. 

This  observation  revealed  that  certain  actions  were  left  unspecified  in  the  Local  Proxy. 
As  an  example,  let  us  consider  the  actions  of  the  complementary  edge  e28-  The  messages 
received  from  TCP/IP  are  of  three  types:  connection  established,  segment  received,  and  con¬ 
nection  closed/aborted.  The  Local  Proxy  takes  appropriate  actions  dictated  by  the  type  of 
message  received  from  TCP/IP.  After  the  action-to-action  and  the  action-to-condition  in¬ 
consistencies  are  removed,  it  must  be  true  for  all  nodes  of  the  subgraph  starting  s16  and 
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ending  s28  of  Figure  4  that  conn.idx  ±  N EG  AT  A.  Thus,  traversing  the  complementary 
edge  of  e28,  with  connJdx  ±  N EG  AT  A  input  and  null  output,  is  feasible.  However,  dis¬ 
cussions  with  the  designers  revealed  that  the  unspecified  actions  were  left  out  by  mistake 
and  e28  should  not  have  been  a  complementary  edge.  The  actions  of  e28,  corresponding  to 
the  TCP /IP  message  signaling  for  connection  established  were  needed  to  be  specified  when 
TCP JCI -IN. INF. TYPE  =  ESTAB  and  conn.idx  ^  NEGATA. 

The  modification  made  to  the  Local  Proxy  specification  based  on  the  reachability  analysis 
demonstrates  the  need  for  integrating  the  protocol  development  with  the  conformance  test 
generation  process.  This  integration  will  allow  for  the  removal  of  costly  mistakes  from  the 
specification  at  an  early  stage  of  the  development,  before  they  propagate  into  many  different 
implementations  possibly  combined  with  other  errors. 


4.3  Structure  of  EFSMs 

Due  to  the  inconsistencies  among  the  actions  and  conditions  [1],  automated  test  gener¬ 
ation  for  EFSM  modeled  protocols  becomes  a  difficult  process.  The  graph  of  EFSM  model 
might  be  split  multiple  times  to  remove  the  inconsistencies,  where  each  split  node  may  in¬ 
crement  the  length  of  the  test  sequence.  The  complexity  of  splitting  nodes  and  edges  of  the 
EFSM  graph  (and  hence  the  length  of  test  sequence)  can  be  reduced  at  the  design  stage  by 
excluding  some  of  the  inconsistencies  from  the  specification,  without  tradeoffs. 

In  general,  a  protocol  can  be  specified  in  several  different  ways  leading  to  different 
FSMs/EFSMs,  all  of  which  accomplish  the  same  task(s).  The  EFSM  model  of  a  VHDL 
specification  consists  of  interconnected  data  flow  subgraphs.  The  topological  interconnec¬ 
tion  among  these  subgraphs  has  a  direct  impact  on  the  length  of  tests  generated  for  the 
EFSM.  A  cascade  of  data  flow  subgraphs  that  use  the  same  conditional  variables  can  be 
interconnected,  such  that  the  number  of  infeasible  paths  are  minimum  (provided  that  the 
controlling  variables  are  not  updated  in  these  data  flow  subgraphs).  By  minimizing  the 
infeasible  paths,  the  test  sequence  length  can  be  shortened. 

Figure  5  shows  two  fragments  of  different  VHDL  specifications,  which  are  equivalent  in 
terms  of  their  functionalities.  However,  their  corresponding  EFSM  models  differ  significantly. 


if  (x  =  1)  then  A  :=  b; 

if  (x  =  1)  then  A  :=  b; 

else  if  (x  =  2)  then  A  :=  c; 

else  null; 

else  null; 

end  if; 

end  if; 

if  (x  =  2)  then  A  :=  c; 

end  if; 

else  null; 
end  if; 

(a) 

0>) 

Figure  5.  Examples  of  Two  VHDL  Specifications. 

All  paths  for  the  EFSM  model  of  Figure  5(a)  are  valid  and  thus  the  EFSM  is  consis¬ 
tent.  On  the  other  hand,  the  EFSM  model  of  Figure  5(b)  contains  condition-to-condition 
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inconsistency  and  an  infeasible  path.  The  EFSM  model  of  Figure  5(b),  therefore,  requires 
mechanisms  to  remove  the  inconsistency,  which  increases  the  complexity  of  the  test  genera¬ 
tion  process. 

A  simple  but  important  example  that  supports  this  case  can  be  found  in  the  Local  Proxy. 
As  stated  in  section  3,  it  is  not  possible  to  include  e27,  637,  and  643  in  the  same  test  sequence. 
This  problem  will  be  resolved  when  the  inconsistencies  are  removed  from  the  EFSM  model. 
The  work  of  splitting  some  nodes,  however,  could  have  been  prevented  if  the  tail  nodes  for 
e28,  e34,  e35,  e38,  e40,  and  e41  were  combined  as  s2 3.  Such  combination  of  tail  states  can  be 
achieved  by  using  the  format  depicted  in  Figure  5(a)  for  conditions  of  outgoing  edges  of  s17, 
s22  and  s 25,  which  currently  use  the  format  of  Figure  5(b). 

Therefore,  where  possible,  the  conformance  testers  provide  recommendations  for  the  sec¬ 
tions  of  the  EFSM  graph  that  requires  heavy  splitting  due  to  inconsistencies.  Restructuring 
the  specification  may  reduce  the  complexity  of  the  test  generation  process,  while  reducing 
the  test  sequence  length. 


5.  Conclusions 


This  report*  proposes  the  integration  of  protocol  specification  and  conformance  test  se¬ 
quence  generation  to  enable  a  more  rigorously  tested  product.  Through  such  an  approach, 
specification  errors  can  be  detected  at  an  early  stage  of  the  development  process.  As  a  case 
study,  the  inconsistency  detection  and  removal  algorithms  of  [1,  2]  with  automated  test  gen¬ 
eration  techniques  of  Aho  et  al.  [9]  are  applied  to  the  VHDL  specification  of  the  Local  Proxy 
component  of  the  AC  A  [3].  Based  on  the  results  of  the  conformance  test  generation  pro¬ 
cess  [1,  2],  various  improvements/recommendations  have  been  submitted  to  the  Local  Proxy 
designers,  such  as  the  identification  of  various  missing  actions,  the  removal  of  redundancies, 
and  the  reorganization  of  portions  of  the  specification  to  enhance  its  testability.  Several 
other  VHDL  specifications  of  protocols  used  in  the  military  are  planned  to  be  studied  within 
this  integrated  framework. 


‘The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  should  not  be 
interpreted  as  representing  the  official  policies,  either  expressed  or  implied,  of  the  Army  Research  Laboratory 
or  the  U.S  Government. 
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Appendix: 

VHDL  Specification  of  the  Local  Proxy 
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library  IEEE; 


use  IEEE.std_logic_1164.all; 
use  IEEE. std_logic_arith. all; 
use  std.all; 


entity  LOCAL-PROXY  is 

port  (USER.CMD:  in  stdJogic; 

TCP-ICI-OUT-INF:  out  std_logic_vector  (0  to  15); 

TCP-ICLOUT-ADDR:  out  std_logic_vector  (0  to  63); 

TCP-ICIJNJNF:  in  stdJogic.vector  (0  to  15); 

TCP-ICIJN-ADDR:  in  stdJogic.vector  (0  to  63); 

CMD_OUT_ADDR:  out  stdJogic.vector  (0  to  63); 

CONNS-OUT-PORT:  out  stdJogic.vector  (0  to  31); 

CONNS-OUT-ADDR:  out  stdJogic.vector  (0  to  63); 

ACCESS.ADDR:  out  stdJogic.vector  (0  to  9); 

LP-MSG.OUT1,  LP.MSG.OUT2,  LP-MSG.OUT3,  LP.MSG.OUT4, 

LP.MSG-OUT5,  LP.MSG.OUT6,  LP.MSG.OUT7,  LP.MSG.OUT8,  LP.MSG.OUT9, 

LP-MSG.OUTIO:  out  stdJogic.vector  (0  to  15); 

TCPJCI-PACKET.INDX:  in  integer); 
end  LOCAL-PROXY;  architecture  LOCAL-PROXY  of  LOCAL-PROXY  is 
begin 
process 

constant  MAX-CONN:  INTEGER:=  10; 
constant  TYPE.0  :  INTEGER—  0; 
constant  TYPE.3  :  INTEGER—  3; 
constant  CONNJD.4:  INTEGER—  4; 
constant  CONNJD.8:  INTEGER—  8; 
constant  STRM.INDX.9  :INTEGER:=  9; 
constant  STRM_INDX.il  :  INTEGER—  11; 
constant  NUM-PKS.12  :  INTEGER:  =  12; 
constant  NUMJ>KS.14  :  INTEGER:  =  14; 
constant  port.block.O  :  INTEGER:=  0; 
constant  port_block_15  JNTEGER—  15; 
constant  URGENT.15  :  INTEGER—  15; 
constant  REMJPORT.32  :  INTEGER—  32; 
constant  REMJPORT.47  :  INTEGER—  47; 
constant  REM-ADDR.48  :  INTEGER:=  48;' 
constant  REM_ADDR_63  :  INTEGER—  63; 
constant  LOCAL.PORT.O  JNTEGER—  0; 
constant  LOCAL.PORT.15  JNTEGER—  15; 
constant  LAST-SIGNAL.O:  INTEGER—  0; 
constant  LAST.SIGNAL.3:  INTEGER:=  3; 
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constant  LAN_REMJPORT_32:  INTEGER:=  32; 

constant  LAN_REM_PORT_47:  INTEGER:  =  47; 

constant  LAN_REM_ADDR_16:  INTEGER:^  16; 

constant  LOCAL.INDEX.O:  INTEGER—  0; 

constant  LOCAL_INDEX_3:  INTEGER:=  3; 

constant  LAN.REM_ADDR.31:  INTEGER:=  31; 

constant  EMPTY  :  std_logic_vector  (0  to  15):=  ”1111111111111111” 

constant  CONNJJNUSED:  stdJogic.vector  (0  to  4):=  ”11111”; 

constant  ZER.0  :  stdJogic.vector  (0  to  15):=  ”0000000000000000”; 

constant  BEGJ3XC  :  stdJogic:=  ’O’; 

constant  END.EXC  :  std_logic:=  ’1’; 

constant  PKT.0:  stdJogic.vector  (0  to  2):=  ”000”; 

constant  PKT.l:  stdJogic.vector  (0  to  2):=  ”001”; 

constant  UNKNOWNJD:  stdJogic.vector  (0  to  4):=  ”00000”; 

constant  NONE:  stdJogic.vector  (0  to  2):=  ”000”; 

constant  MSG-OPEN:  stdJogic.vector  (0  to  3):=  ”0001”; 

constant  LANJRX:  stdJogic.vector  (0  to  3):=  ”0010”; 

constant  MSGJRX:  stdJogic.vector  (0  to  3):=  ”0011”; 

constant  MSG_CLOSE:std_logic_vector  (0  to  3):=  ”0100”; 

constant  CLOSE:  stdJogic.vector  (0  to  3):=  ”0101”; 

constant  ABORT:stdJogic_vector  (0  to  3):=  ”0110”; 

constant  SEG_FWD:stdJogic_vector  (0  to  3):=  ”0111”; 

constant  ESTAB:stdJogic_vector  (0  to  3):=  ”1111”; 

constant  FIRST.LP:std.logic.vector(0  to  9):=  ”0000000001”; 

constant  SECOND.LP:stdJogic_vector(0  to  9):=  ”0000000010”; 

constant  THIRD  _LP:std_logic_vector(0  to  9):=  ”0000000100”; 

constant  FOURTHXP:std_logic_vector(0  to  9):=  ”0000001000”; 

constant  FIFTHXP:std.logic.vector(0  to  9):=  ”0000010000”; 

constant  SIXTH_LP:std.logic.vector(0  to  9):=  ”0000100000”; 

constant  SEVENTH.LP:std.logic_vector(0  to  9):=  ”0001000000”; 

constant  EIGHTHJLP:std.logic.vector(0  to  9):=  ”0010000000”; 

constant  NINETH_LP:stdJogic.vector(0  to  9):=  ”0100000000”; 

constant  TENTHXP:std.logic.vector(0  to  9):=  ”1000000000”; 

constant  NO_LP:std_logic_vector(0  to  9):=  ”0000000000”; 

constant  CMD.OPEN.ACTIVE  :  stdJogic.vector  (0  to  3):=  ”0001”; 

constant  CMD.OPENJPASSIVE  :  stdJogic.vector  (0  to  3):=”0010”; 

constant  CMD.CLOSE  :  stdJogic.vector  (0  to  3):=”0011”; 

constant  CMD.ABORT:  stdJogic.vector  (0  to  3):=”0100”; 

constant  CMD.RECEIVE:  stdJogic.vector  (0  to  3):=”0101”; 

subtype  cmd_addr  is  stdJogic.vector (0  to  63); 

subtype  cmdJnf  is  std.logic.vector(0  to  15); 

subtype  ind_addr  is  std.logic.vector(0  to  63); 

subtype  ind-inf  is  std.logic.vector(0  to  15); 

subtype  connJn  is  stdJogic.vector(0  to  15); 

type  conns_in_array  is  array  (0  to  MAX.CONN-l)  of  connJn; 
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subtype  conn.por  is  std_logic_vector(0  to  63); 

type  conns_por_array  is  array  (0  to  MAX-CONN-l)  of  conn.por; 

subtype  conn.add  is  stdJogic.vector(0  to  63); 

type  conns_add_array  is  array  (0  to  MAX.CONN-l)  of  conn_add; 

constant  LAN-PROXY.PORT:  stdJogic.vector  (0  to  15):=  ”0000100000000000”; 

constant  PORT -BLOCK-START:  std_logic_vector  (0  to  15):=  ”0000100000000000”  ; 

constant  LAN-PROXY-ADDRESS:  stdJogic.vector  (0  to  15):=  ”0000001000000000”; 

constant  LANJDX:  INTEGER:=  0; 

constant  NEGAT.l:  INTEGER:=  -1; 

constant  SERVER-PORT:  stdJogic.vector  (0  to  15):=  ”0000010000000000”; 
constant  DELTA-1:  stdJogic.vector  (0  to  15):=  ”0000000000000001”; 

-  -  Declare  all  the  variables  here. 

variable  conns_inf:  conns_in_array; 

variable  conns_addr:  conns_add_array; 

variable  conns.port:  conns_por_array; 

variable  tempJnf:  cmdinf; 

variable  msgl:  cmdJnf; 

variable  cmdJciJnf:  cmdJnf; 

variable  cmd Jci-addr:  cmd-addr; 

variable  indJciJnf:  cmdJnf; 

variable  indJci_addr:  cmd-addr; 

variable  port-block:  stdJogic.vector  (0  to  15); 

variable  i:  INTEGER; 

variable  conn-id:  stdJogic.vector (0  to  4); 

variable  connJdx:  INTEGER; 

variable  tempJndex:  INTEGER; 

variable  LANJPROXY-ADDR:  std.logic_vector(0  to  15); 

. Actual  process  starts  here . 

begin 

wait  on  USER.CMD; 
if  (USER.CMD  =  BEGJEXC)  then 

- Do  initialization  .  . . . . . 

tempJnf  (CONNJD.4  to  CONN.ID.8):=  CONN.UNUSED; 
for  i  in  0  to  MAX-CONN  loop 
conns_inf(i):=  tempJnf; 
end  loop; 

wait  for  103000  ms; 
port-block:  =  PORT-BLOCK-START; 
cmdJciJnf(TYPE_0  to  TYPE-3) :=  CMD_OPEN_ACTIVE; 
cmdJciJnf(CONN.ID_4  to  CONNJD_8):=  UNKNOWN JD; 
cmdJciJnf(STRMJNDX_9  to  STRM.INDX.il) :=  NONE; 
cmdJciJnf(NUMJPKS_12  to  NUM_PKS_14):=  PKT.0; 
cmdJciJnf(URGENT_15):=  ’O’; 

cmdJci_addr(port_block_0  to  port_block_15):=  port-block; 
cmdJci-addr(REM-PORT_32  to  REM.PORT.47):=  LAN  .PROXY .PORT; 
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cmdici-addr(REM_ADDR_48  to  REM_ADDR_63):=  LAN.PROXY.ADDR; 
port_block:=  port-block  -f  DELTA-1; 
cmdJciJnf(NUM_PKS_12  to  NUMJPKS.14):=  PKT.O; 

-  -  Now  output  the  ICI  to  TCP 
TCPJCI-OUTJNF  <=  cmdiciinf; 

TCP-ICLOUT-ADDR  <=  cmdici_addr; 

. . -  This  is  now  the  START  state . - . 

wait  on  TCP-ICIJNJNF,  USER.CMD; 
if  (USER.CMD  /=  END.EXC)  then 

while  (TCP-ICIJNJNF(TYPE_0  to  TYPE-3)  /=  ESTAB)  loop 

-  -  This  is  the  LAN-OP  state 

conn_id:=  TCP-ICI-INJNF(CONNJD_4  to  C0NN_ID_8); 

tempJnf(C0NNJD_4  to  CONN_ID_8):=  TCP-ICIJNJNF(CONNJD_4  to  CONNJD-8); 
connidx:=  LAN.IDX; 

tempinf(STRMJNDX_9  to  STRM_INDXJ1):=  NONE; 
conns_addr(conn_idx):=  TCP_ICI_IN_ADDR; 
conns.port  (conn_idx) :  =  TCP.ICI  JN-ADDR; 

-  -  CONNS_OUT_PORT  <=  conns_port(conn_idx); 

CONNS-OUT-ADDR  <=  conns_addr(conn_idx); 
cmdiciinf: =  TCP-ICIJNJNF; 
cmdiciinf(NUM-PKS_12  to  NUM_PKS_14):=  PKT.l; 
cmdiciinf(TYPE_0  to  TYPE_3):=  CMDJRECEIVE; 

TCPJCI-OUTJNF  <=  cmdiciinf; 

TCP_ICI_OUT_ADDR  <=  cmd_ici_addr;  -  -  consist  of  ports  and  addrs 
CMD_OUT_ADDR  <=  cmdicLaddr; 
conns_inf(conn_idx):=  tempJnf; 
wait  on  TCP-ICIJNJNF,  USER.CMD; 
end  loop; 
wait  for  1000  ms; 

-  -  Then  open  passively  for  application  clients 

-  -  This  is  state  Pending 

cmdJci_inf(CONNJD_4  to  CONN_ID.8):=  UNKNOWN JD; 
cmdici-addr(REM-PORT_32  to  REM_PORT_47):=  EMPTY; 
cmdJci_addr(LOCAL_PORT.O  to  LOCAL_PORT_15):=  SERVER-PORT; 
cmdJci_addr(REM_ADDR_48  to  REM_ADDR_63):=  ZER.O; 
cmdJciJnf(TYPE_0  to  TYPE.3):=  CMD-OPEN.PASSIVE; 
cmdJciinf(NUM_PKS_12  to  NUM_PKS_14):=  PKT.O; 

TCPJCI-OUTJNF  <=  cmdiciinf; 

TCPJCI-OUT-ADDR  <=  cmdici_addr; 

CMD_OUT_ADDR  <=  cmdicLaddr; 

-  -  Process  anything  from  LAN  or  application 

-  -  This  is  the  LISTEN  state 

wait  on  USER.CMD,  TCP-ICIJNJNF; 
while  (USER.CMD  /=  END.EXC)  loop 
indiciinf:=  TCP-ICIJNJNF; 
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incLici_addr:=  TCP  JCIJN-ADDR; 

conn_id:=  ind_iciinf(C0NNJD-4  to  C0NNJD.8); 

-  -  Work  out  the  conn_idx 
if  (connJd  =  CONN_UNUSED)  then 
conn_idx:=  NEGAT-1; 
else 

i:=  0  ; 

tempinf:=  conns_inf(i); 
while  (i  <  MAX-CONN  and 

tempjnf(CONN_ID_4  to  CONN-ID .8)  /=  conn-id)  loop 
i:=  i  +  1; 

temp-inf: =  conns_inf(i); 
end  loop; 

if  (i  <  MAX-CONN)  then 
conn_idx:=  i; 
else 

conn_idx:=  NEGAT-l ; 
end  if; 
end  if; 

if  (indJciinf(TYPE_0  to  TYPE.3)  =  ESTAB)  then 
if  (connJdx  =  NEGAT-l)  then 

. -  -  DoOpen - - 

-  -  find  an  empty  spot  in  the  connection  array 
i:=  1;  -  -  0  reserved  for  LAN  proxy 
tempinf:=  conns_inf(l); 
while  (i  <  MAX_CONN  and 

temp_inf(CONN_ID_4  to  C0NN_ID_8)  /=  CONN_UNUSED)  loop 
i:=  i+1; 

tempinf:=  conns_inf(i); 
end  loop; 

if  (i  <  MAX-CONN)  then 
conn_idx:=  i; 

conns_inf(conn_idx):=  indJci_inf; 
conns_addr(conn_idx):=  ind_ici_addr; 

conns_port(conn_idx):=  conns_port(LAN_IDX);  -  -  for  LAN  info. 

-  -  Do  another  passive  open 

cmdici  jnf(TYPE_0  to  TYPE_3):=  CMD.OPEN .PASSIVE; 
cmdici_inf(C0NN_ID_4  to  C0NNJD.8):=  UNKNOWNJD; 
cmdici-addr(LOCAL-PORT_0  to  L0CAL_P0RT.15):=  SERVER-PORT; 
cmdJci-addr(REMJPORT-32  to  REM_PORT.47):=  EMPTY; 
cmdici_addr(REM-ADDR_48  to  REM.ADDR_63):=  ZER.O;  -  -  ie  no  address 
cmdJciJnf(NUM_PKS_12  to  NUM-PKS_14):=  PKT.O; 

TCP-ICI-OUT-INF  <=  cmdiciinf; 

TCP_ICLOUT_ADDR  <=  cmdici-addr; 

-  -  Now  send  the  ICI  to  the  Local  Proxy2  process 
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-  -  this  is  to  avoid  a  spawn  !! 

-  -  conns Jnf(conn_idx,  TYPE_0  to  TYPE.3  ):=  MSG-OPEN; 
temp_inf:=  conns.inf(connJdx); 

tempinf(TYPE_0  to  TYPE.3  ):=  MSG-OPEN; 
conns_inf  (conn_idx):=  tempinf; 
msgl:=  conns_inf(connJdx); 
case  i  is 

when  0  =>  LP.MSG.0UT1  <=  msgl; 

ACCESS-ADDR(0  to  9)  <=  FIRST.LP; 
when  1  =>  LP.MSG.0UT2  <=  msgl; 

ACCESS.ADDR(0  to  9)  <=  SECOND.LP; 
when  2  =>  LP.MSG.0UT3  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  THIRD _LP; 
when  3  =>  LP_MSG_0TJT4  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FOURTHXP; 
when  4  =>  LP.MSG.0UT5  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FIFTHJLP; 
when  5  =>  LP.MSG.0UT6  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SIXTHJLP; 
when  6  =>  LP.MSG.0UT7  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SEVENTHJLP; 
when  7  =>  LP.MSG.0UT8  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  EIGHTHJLP; 
when  8  =>  LP.MSG-0UT9  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  NINETHXP; 
when  9  =>  LP.MSG.OUT10  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  TENTHXP; 
when  others  => 

ACCESS.ADDR(0  to  9)  <=  NOXP; 
end  case; 
end  if; 
end  if; 
end  if; 

if  (indici_inf(TYPE.O  to  TYPE.3)  =  SEG.FWD)  then 

. DoSegFwd . . . . 

- Ask  to  read  from  socket. 

cmdiciinf(C0NNJD_4  to  C0NN_ID_8):=  UNKNOWN JD; 
cmd_ici.addr(REM_PORT_32  to  REM.PORT.47):=  EMPTY; 
cmdJci^ddr(REM_ADDR_48  to  REM_ADDR_63):=  ZER.O; 
cmdici_addr(LOCAL_PORT.O  to  L0CAL.P0RT_15):=  SERVERJPORT; 
cmd_ici_inf(NUM_PKS_12  to  NUMXKS_14):=  PKT.1; 
cmdiciinf(TYPE.O  to  TYPE.3) :=  CMD.RECEIVE; 

TCP.ICLOUT.INF  <=  cmdJciJnf; 

TCP_ICI.OUT.ADDR  <=  cmdici_addr; 
if  (conn_idx  /=  NEGAT.l)  then 
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-  -  connection  is  valid 

if  (connJdx  =  LAN.IDX)  then 

tempJndex:=  TCPJCIJPACKET.INDX; 
tempJnf:=  conns_inf(tempJndex); 
tempJnf(TYPE_0  to  TYPE.3):=  LAN_RX; 
else 

-  -  Received  a  packet  from  the  application 
temp  _inf:=  conns.inf  (connJdx); 
tempJnf(TYPE_0  to  TYPE.3):=  MSG.RX; 
end  if; 

-  -  Now  send  the  ICI  to  the  Local  Proxy2  process 

-  -  this  is  a  kludge  to  avoid  a  spawn  !! 
conns_inf(conn_idx):=  tempJnf; 
msgl:=  conns-inf(connidx); 

case  i  is 

when  0  =>  LP_MSG_0UT1  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FIRST.LP; 
when  1  =>  LP-MSG.OUT2  <=  msgl; 

ACCESS-ADDR(0  to  9)  <=  SECOND.LP; 
when  2  =>  LP-MSG-0UT3  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  THIRD _LP; 
when  3  =>  LP.MSG.0UT4  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FOURTHJLP; 
when  4  =>  LP.MSG.0UT5  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FIFTHXP; 
when  5  =>  LP_MSG_0UT6  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SIXTH-LP; 
when  6  =>  LP.MSG-0UT7  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SEVENTH-LP; 
when  7  =>  LP.MSG-0UT8  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  EIGHTH.LP; 
when  8  =>  LP.MSG.0UT9  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  NINETHJLP; 
when  9  =>  LP_MSG_OUT10  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  TENTH.LP; 
when  others  => 

ACCESS.ADDR(0  to  9)  <=  NOXP; 
end  case; 
end  if; 
end  if; 

if  (indJciJnf  (TYPE.O  to  TYPE.3)  =  CLOSE  or 

indJciinf(TYPE_0  to  TYPE.3)  =  ABORT)  then 
-  -  ICIJNT.TYPE  =  INT.CLOSE  or  INT.ABORT 

- DoClose . 

if  (connJdx  /=  NEGAT.l)  then 
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-  -  connection  is  valid 

if  (connJdx  /=  LAN.IDX)  then 
temp  inf:=  conns_inf(conn_idx); 
tempinf(TYPE_0  to  TYPE_3):=  MSG.CLOSE; 
conns_inf(conn_idx):=  tempinf; 
end  if; 

-  -  Now  send  the  ICI  to  the  Local  Proxy2  process 

-  -  this  is  a  kludge  to  avoid  a  spawn  !! 
msgl:=  connsJnf(connJdx); 

case  i  is 

when  0  =>  LP_MSG_0UT1  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FIRST_LP; 
when  1  =>  LP-MSG-0UT2  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SECOND.LP; 
when  2  =>  LP_MSG_0UT3  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  THIRD.LP; 
when  3  =>  LP_MSG_0UT4  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FOURTHJLP; 
when  4  =>  LP_MSG_0UT5  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  FIFTHXP; 
when  5  =>  LP_MSG_0UT6  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SIXTH-LP; 
when  6  =>  LP_MSG_0UT7  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  SEVENTH.LP; 
when  7  =>  LP_MSG_0UT8  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  EIGHTH.LP; 
when  8  =>  LP-MSG.0UT9  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  NINETHXP; 
when  9  =>  LP-MSG.OUTIO  <=  msgl; 

ACCESS_ADDR(0  to  9)  <=  TENTH.LP; 
when  others  => 

ACCESS_ADDR(0  to  9)  <=  NO.LP; 
end  case; 
end  if; 
end  if; 

wait  on  USER.CMD,  TCP  JCIJN  JNF; 
end  loop; 
end  if; 
end  if; 
end  process; 
end  LOCAL-PROXY ; 
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Table  A-l.  Edge  Conditions  for  the  Local  Proxy 


Edge 

Condition 

e0 

1  =  1 

el 

USER-CMD  =  USER_CMD_1 

e2 

USER_CMD_1  /  BEG.EXC 

^3 

USER-CMD.l  =  BEG-EXC 

e4 

i  <  MAX-CONN 

^4.1 

1  =  1 

e5 

i  >=  MAX_C0NN 

ee 

1  =  1 

^7 

TCP-ICLINJNF  =  TCPJCIJNJNF.1  or  USER-CMD  =  USER_CMD_2 

e8 

USR-CMD  =  END-EXC 

e9 

USR-CMD  ^  END-EXC 

610 

TCP  JCIJNJNF.TYPE  =  ESTAB 

Cll 

TCP-ICIJN JNF.TYPE  ^  ESTAB 

612 

1  =  1 

^13 

TCP-ICI-INJNF  =  TCP-ICIJN JNF.2  or  USER_CMD  =  USER-CMD-3 

ei4 

1  =  1 

eis 

TCP JCIJNJNF  =  TCP-ICIJN JNF_3  or  USER-CMD  =  USER_CMD_4 

Cie 

USR-CMD  =  END-EXC 

Cl7 

USR_CMD  ^  END-EXC 

eis 

conn-id  #  CONN-UNUSED 

£19 

conn  Jd  =  CONN-UNUSED 

620 

i  >=  MAX-CONN 

621 

i  <  MAX_CONN 

622 

conns(i).connJd  ^  condJd 

623 

conns(i).connJd  =  condJd 

624 

i  >=  MAX-CONN 

625 

i  <  MAX-CONN 

626 

TCP  JCIJNJNF.TYPE  ^  ESTAB 

627 

TCP  JCIJNJNF.TYPE  =  ESTAB 

e28 

conn_idx  ^  NEGAT.l 

629 

connJdx  =  NEGAT.l 

630 

i  >=  MAX-CONN 

631 

i  <  MAX-CONN 

632 

conns(i).conn_id  ^  condJd 

633 

conns(i).connJd  =  cond-id 

634 

i  >=  MAX-CONN 

635 

i  <  MAX-CONN 

e36 

TCP  JCIJNJNF.TYPE  ^  SG.FWD 

637 

TCP-ICIJN  JNF.TYPE  =  SG.FWD 

638 

connJdx  =  NEGAT.l 

639 

connJdx  ^  NEGAT.1 
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Edge  Conditions  for  the  Local  Proxy  (Continued) 


Edge 

Condition 

£40 

connJdx  ^  LANJDX 

e4i 

connJdx  =  LANJDX 

£42 

TCPJCI-IN  JNF.TYPE  ^  CLOSE  or  ABORT 

643 

TCP_ICI.INJNF.TYPE  =  CLOSE  or  ABORT 

644 

connJdx  ^  NEGAT.l 

645 

connJdx  =  NEGAT.1 

£46 

connJdx  ^  LANJDX 

e47 

connJdx  =  LANJDX 

^48 

1  =  1 

^49 

TCPJCIJNJNF  =  TCPJCI-IN JNF.4  or  USER.CMD  =  USER.CMD.5 
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Table  A-2.  Test  Sequence  for  the  Local  Proxy 


Step 

From  State 

To  State 

Input/ Output 

1 

NO 

N1 

10/01 

2 

N1 

N2 

11/03 

3 

N2 

N2 

verify  N2 

4 

N2 

N3 

13/03 

5 

N3 

N3 

verify  N3 

6 

N3 

N3 

14/04 

7 

N3 

N4 

15/05 

8 

N4 

N4 

verify  N4 

9 

N4 

N5 

16/06 

10 

N5 

N5 

verify  N5 

11 

N5 

N6 

17/07 

12 

N6 

N6 

verify  N6 

13 

N6 

N7 

19/09 

14 

N7 

N7 

verify  N7 

15 

N7 

N8 

111/011 

16 

N8 

N8 

verify  N8 

17 

N8 

N9 

112/012 

18 

N9 

N9 

verify  N9 

19 

N9 

N7 

113/013 

20 

N7 

N10 

110/010 

21 

N10 

N10 

verify  N10 

22 

N10 

Nil 

114/014 

23 

Nil 

Nil 

verify  Nil 

24 

Nil 

N12 

115/015 

25 

N12 

N12 

verify  N12 

26 

N12 

N13 

117/025 

27 

N13 

N13 

verify  N13 

28 

N13 

N14 

118/018 

29 

N14 

N15 

128/028 

30 

N15 

N15 

verify  N15 

31 

N15 

N16 

123/023 

32 

N16 

N16 

verify  N16 

33 

N16 

N17 

125/025 

34 

N17 

N17 

verify  N17 

35 

N17 

N22.1 

126/026 

36 

N22.1 

N22.1 

verify  N22.1 

37 

N22.1 

N25.1 

136.1/036.1 

38 

N25.1 

N25.1 

verify  N25.1 

39 

N25.1 

N26 

143/043 

40 

N26 

N26 

verify  N26 
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Test  Sequence  for  the  Local  Proxy  (Continued) 


Step 

From  State 

To  State 

Input/Output 

41 

N26 

N27 

144/044 

42 

N27 

N27 

verify  N27 

43 

N27 

N28 

147/047 

44 

N28 

N28 

verify  N28 

45 

N28 

N29 

148/028 

46 

N29 

N29 

verify  Ns29 

47 

N29 

N29 

verify  N29 

48 

N29 

N12 

149/049 

49 

N12 

N13 

117/025 

50 

N13 

N14 

118/018 

51 

N14 

N15 

128/028 

52 

N15 

N16 

123/023 

53 

N16 

N17 

125/025 

54 

N17 

N22.1 

126/026 

55 

N22.1 

N25.1 

136.1/036.1 

56 

N25.1 

N26 

143/043 

57 

N26 

N27 

144/044 

58 

N27 

N28 

146/046 

59 

N28 

N29 

148/028 

60 

N29 

N12 

149/049 

61 

N12 

N13 

117/025 

62 

N13 

N14 

118/018 

63 

N14 

N15 

128/028 

64 

N15 

N16 

123/023 

65 

N16 

N17 

i 

125/025 

66 

N17 

N22.1 

126/026 

67 

N22.1 

N23 

137/037 

68 

N23 

N23 

verify  N23 

69 

N23 

N24 

139/039 

70 

N24 

N24 

verify  N24 

71 

N24 

N25 

141/041 

72 

N25 

N25 

verify  N25 

73 

N25 

N28 

142/042 

74 

N28 

N29 

148/028 

75 

N29 

N12 

149/049 

76 

N12 

N13 

117/025 

77 

N13 

N14 

118/018 

78 

N14 

N15 

128/028 

79 

N15 

N16 

123/023 

80 

N16 

N17 

125/025 
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Test  Sequence  for  the  Local  Proxy  (Continued) 


Step 

From  State 

To  State 

Input/Output 

81 

N17 

N22.1 

126/026 

82 

N22.1 

N23 

137/037 

83 

N23 

N24 

139/039 

84 

N24 

N25 

140/040 

85 

N25 

N28 

142/042 

86 

N28 

N29 

148/028 

87 

N29 

N12 

149/049 

88 

N12 

N13 

117/025 

89 

N13 

N14 

118/018 

90 

N14 

N15 

128/028 

91 

N15 

N16 

123/023 

92 

N16 

N17 

125/025 

93 

N17 

N18 

127/027 

94 

N18 

N18 

verify  N18 

95 

N18 

N22 

128/028 

96 

N22 

N22 

verify  N22 

97 

N22 

N25 

136/036 

98 

N25 

N28 

142/042 

99 

N28 

N29 

148/028 

100 

N29 

N12 

149/049 

101 

N12 

N13 

117/025 

102 

N13 

N14 

118/018 

103 

N14 

N15 

128/028 

104 

N15 

N14 

122/022 

105 

N14 

N14 

verify  N14 

106 

N14 

N16.1 

120/020 

107 

N16.1 

N17.1 

124/024 

108 

N17.1 

N17.1 

verify  N17.1 

109 

N17.1 

N18.1 

127.1/027.1 

110 

N18.1 

N18.1 

verify  N18.1 

111 

N18.1 

N19 

129/029 

112 

N19 

N19 

verify  N19 

113 

N19 

N20 

131/031 

114 

N20 

N20 

verify  N20 

115 

N20 

N21.1 

133/033 

116 

N21.1 

N21.1 

verify  N21.1 

117 

N21.1 

N22.3 

135/035 

118 

N22.3 

N22.3 

verify  N22.3 

119 

N22.3 

N25.3 

136.3/036.3 

120 

N25.3 

N25.3 

verify  N25.3 
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Test  Sequence  for  the  Local  Proxy  (Continued) 


Step 

From  State 

To  State 

Input/Output 

121 

N25.3 

N28.1 

142.2/042.2 

122 

N28.1 

N28.1 

verify  N28.1 

123 

N28.1 

N29 

148.1/048.1 

124 

N29 

N12 

149/049 

125 

N12 

N13 

117/025 

126 

N13 

N17.1 

119/019 

127 

N17.1 

N18.1 

127.1/027.1 

128 

N18.1 

N19 

129/029 

129 

N19 

N20 

131/031 

130 

N20 

N19 

132/032 

131 

N19 

N21 

130/030 

132 

N21 

N21 

verify  N21 

133 

N21 

N22.2 

134/034 

134 

N22.2 

N22.2 

verifyN  22.2 

135 

N22.2 

N25.2 

136.2/036.2 

136 

N25.2 

N25.2 

verify  N25.2 

137 

N25.2 

N29 

142.1/042.1 

138 

N29 

N12 

149/049 

139 

N12 

N13 

117/025 

140 

N13 

N17.1 

119/019 

141 

N17.1 

N22.4 

126.1/026.1 

142 

N22.4 

N22.4 

verify  N22.4 

143 

N22.4 

N23.1 

137.1/037.1 

144 

N23.1 

N23.1 

verify  N23.1 

145 

N23.1 

N25.5 

138/038 

146 

N25.5 

N25.5 

verify  N25.5 

147 

N25.5 

N28.2 

142.4/042.4 

148 

N28.2 

N28.2 

verify  N28.2 

149 

N28.2 

N28.2 

verify  N28.2 

150 

N28.2 

N28.2 

verify  N28.2 

151 

N28.2 

N29 

148.2/048.2 

152 

N29 

N12 

149/049 

153 

N12 

N13 

117/025 

154 

N13 

N17.1 

119/019 

155 

N17.1 

N22.4 

126.1/026.1 

156 

N22.4 

N25.4 

136.4/036.4 

157 

N25.4 

N25.4 

verify  N25.4 

158 

N25.4 

N26.1 

143.1/043.1 

159 

N26.1 

N26.1 

verify  N26.1 

160 

N26.1 

N27.1 

145/045 
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Test  Sequence  for  the  Local  Proxy  (Continued) 


Step 

From  State 

To  State 

Input/Output 

161 

N27.1 

N27.1 

verify  N27.1 

162 

N27.1 

N28.2 

147.1/047.1 

163 

N28.2 

N29 

148.2/048.2 

164 

N29 

N12 

149/049 

165 

N12 

N13 

117/025 

166 

N13 

N17.1 

119/019 

167 

N17.1 

N22.4 

126.1/026.1 

168 

N22.4 

N25.4 

136.4/036.4 

169 

N25.4 

N26.1 

143.1/043.1 

170 

N26.1 

N27.1 

145/045 

171 

N27.1 

N28.2 

146.1/046.1 

172 

N28.2 

N29 

148.2/048.2 

173 

N29 

N12 

149/049 

174 

N12 

N13 

117/025 

175 

N13 

N17.1 

119/019 

176 

N17.1 

N22.4 

126.1/026.1 

177 

N22.4 

N25.4 

136.4/036.4 

178 

N25.4 

N28.2 

142.3/042.3 

179 

N28.2 

N29 

148.2/048.2 

180 

N29 

N12 

149/049 

181 

N12 

NO 

116/016 

182 

NO 

N1 

10/01 

183 

N1 

N2 

11/03 

184 

N2 

N3 

13/03 

185 

N3 

N4 

15/05 

186 

N4 

N5 

16/06 

187 

N5 

N6 

17/07 

188 

N6 

NO 

18/08 

189 

NO 

N1 

10/01 

190 

N1 

N2 

11/03 

191 

N2 

NO 

12/02 

192 

NO 

NO 

verify  NO 
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Intentionally  left  blank. 


30 


NO.  OF 

COPIES  ORGANIZATION 

2  DEFENSE  TECHNICAL 
INFORMATION  CENTER 
DTIC  DDA 

8725  JOHN  J  KINGMAN  RD 
STE  0944 

FT  BELVOIR  VA  22060-6218 

1  HQDA 

DAMOEDQ 
D  SCHMIDT 
400  ARMY  PENTAGON 
WASHINGTON  DC  20310-0460 

1  OSD 

OUSD(A&T)/ODDDR&E(R) 
RJTREW 
THE  PENTAGON 
WASHINGTON  DC  20301-7100 

1  DPTY  CG  FOR  RDE  HQ 
US  ARMY  MATERIEL  CMD 
AMCRD 
MG  CALDWELL 
5001  EISENHOWER  AVE 
ALEXANDRIA  VA  22333-0001 

1  INST  FOR  ADVNCD  TCHNLGY 

THE  UNIV  OF  TEXAS  AT  AUSTIN 
PO  BOX  202797 
AUSTIN  TX  78720-2797 

1  DARPA 
BKASPAR 
3701  N  FAIRFAX  DR 
ARLINGTON  VA  22203-1714 

1  NAVAL  SURFACE  WARFARE  CTR 
CODE  B07  J  PENNELLA 
17320  DAHLGRENRD 
BLDG  1470  RM  1101 
DAHLGREN  VA  22448-5100 

1  US  MILITARY  ACADEMY 

MATH  SCI  CTR  OF  EXCELLENCE 
DEPT  OF  MATHEMATICAL  SCI 
MAJ  M  D  PHILLIPS 
THAYER  HALL 
WEST  POINT  NY  10996-1786 


NO.  OF 

COPIES  ORGANIZATION 

1  DIRECTOR 
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